\documentclass[12pt]{article}
\usepackage{amsmath,amsthm,amssymb}
\usepackage{times}
\usepackage{verbatim}

\newtheorem{defn}{Definition}
\newtheorem{lem}{Lemma}
\newtheorem{thm}{Theorem}

\begin{document}
\section*{Administrivia}
\begin{itemize}
\item A couple of people have managed to communicate with the train, so it
\textit{is} possible!
\item If the train controller doesn't respond, you should time out. If it
repeatedly doesn't respond - say, 2 or 3 times - you should give up.
\item To know the initial state of the switches, you must set the initial
state of the switches. (You may assume that the trains have initial speed 0.)
\end{itemize}

\section*{RS-232, continued}
\paragraph{}
We discussed an old protocol for forcing a block until the buffer can be
freed up, which involves the use of special \texttt{XOFF} and \texttt{XON}
markers. There is a problem: the transmission of \texttt{XOFF} is not
instantaneous, which means that the sender can continue to send data right
up until it receives and processes the \texttt{XOFF}.
\paragraph{}
The standard way instead uses something called Hardware Flow Control. Both
parties have the following signals:
\begin{itemize}
\item \texttt{RTS}: ready to send. This party is ready to send data.
\item \texttt{CTS}: clear to send. The other party is ready to receive data.
\item \texttt{DTR}: data terminal ready.
\item \texttt{DSR}: data set ready.
\end{itemize}
\paragraph{}
Before sending any data, you check \texttt{CTS}; if this bit is set, you may
send data.

\section*{Kernel}
\paragraph{}
A kernel provides tasks. Tasks are entities that receive requests and respond 
to them. This is similar to the concept of an \textit{object} in OOP; they
are lighter than processes, but heavier than threads. Tasks must be able to
\begin{itemize}
\item communicate, or pass messages between each other;
\item synchronize, or wait on each other.
\end{itemize}
\paragraph{}
To manipulate tasks, you need a data structure that stores the current state
of the tasks, along with a scheduling algorithm for sharing the CPU and other
resources among them.
\paragraph{}
We will be making what is known as a \textit{microkernel}. The principal ideas
of a microkernel are simplicity and minimalism; it does the bare minimum
required to marshal resources and tasks, and delegates as much as possible to
modules that handle things like device I/O. In this sense, the I/O facilities
are not part of the kernel itself.
\paragraph{}
On an incredibly vague level, the kernel looks like this:
\begin{verbatim}
initialize();
FOREVER {
  active = schedule( active );
  request = get_request( active );
}
\end{verbatim}
\paragraph{}
In turn, \texttt{get\_request()} does several things:
\begin{itemize}
\item pick up the stack of the newly active task;
\item load the state of that task into the CPU;
\item set the instruction register to the start of that task.
\end{itemize}
\paragraph{}
The task then begins to execute a bunch of instructions that the kernel
largely doesn't care about, save for one: the \textit{software interrupt}.
By issuing a software interrupt, a task can yield control back to the kernel.
\paragraph{}
The ARM processor places the program counter in register 15. Register 14 is
called the link register; the standard way to call a subroutine is to put the
current program counter into the link register, then load the new program
counter into the program counter. To return from a subroutine, you merely
reverse the process.
\paragraph{}
The software interrupt, then, does something very devious: it loads the value
\texttt{0x8} into the program counter, at which location you will find some
instructions - typically, these are branch instructions, used to provide an
entry point to the kernel (or something else.)
\end{document}
